The QSPI controller has two interconnect paths:
1. qspi-config: CPU to QSPI controller for register access
2. qspi-memory: QSPI controller to memory for DMA operations

Currently, the driver only manages the qspi-config path. Add support for
the qspi-memory path to ensure proper bandwidth allocation for QSPI data
transfers to/from memory. Enable and disable both paths during runtime PM
transitions.

Link: https://patch.msgid.link/20260324-spi-nor-v1-2-3efe59c1c119@oss.qualcomm.com
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>

…oller support

Document a DeviceTree property to describe QUP-based I2C controllers that
are shared with one or more other system processors.

On some Qualcomm platforms, a QUP-based I2C controller may be accessed by
multiple system processors (for example, APPS and DSP). In such
configurations, the operating system must not assume exclusive ownership
of the controller or its associated hardware resources.

The new qcom,qup-multi-owner property indicates that the controller is
externally shared and that the operating system must avoid operations
which rely on sole control of the hardware.

Link: https://lore.kernel.org/all/20260331114742.2896317-2-mukesh.savaliya@oss.qualcomm.com/
Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>

…I2C transfers

Some platforms use a QUP-based I2C controller in a configuration where the
controller is shared with another system processor (described in DT using
qcom,qup-multi-owner). In such setups, GPI hardware lock/unlock TREs can be
used to serialize access to the controller.

Add support to emit lock and unlock TREs around I2C transfers and increase
the maximum TRE count to account for the additional elements.

Also simplify the client interface by replacing multiple boolean fields
(shared flag and message position tracking) with a single lock_action
selector (acquire/release/none), as the GPI driver only needs to know
whether to emit lock/unlock TREs for a given transfer.

Link: https://lore.kernel.org/all/20260331114742.2896317-3-mukesh.savaliya@oss.qualcomm.com/
Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>

…trollers

On platforms where a GENI Serial Engine is shared with another system
processor, selecting the "sleep" pinctrl state can disrupt ongoing
transfers initiated by the other processor.

Teach geni_se_resources_off() to skip selecting the pinctrl sleep state
when the Serial Engine is marked as shared, while still allowing the
rest of the resource shutdown sequence to proceed.

This is required for multi-owner configurations (described via DeviceTree
with qcom,qup-multi-owner on the protocol controller node).

Link: https://lore.kernel.org/all/20260331114742.2896317-4-mukesh.savaliya@oss.qualcomm.com/
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>

Some platforms use a QUP-based I2C controller in a configuration where the
controller is shared with another system processor. In this setup the
operating system must not assume exclusive ownership of the controller or
its associated pins.

Add support for enabling multi-owner operation when DeviceTree specifies
qcom,qup-multi-owner. When enabled, mark the underlying serial engine as
shared so the common GENI resource handling avoids selecting the "sleep"
pinctrl state, which could disrupt transfers initiated by the other
processor.

For GPI mode transfers, request lock/unlock TRE sequencing from the GPI
driver by setting a single lock_action selector per message, emitting lock
before the first message and unlock after the last message (handling the
single-message case as well). This serializes access to the shared
controller without requiring message-position flags to be passed into the
DMA engine layer.

Link: https://lore.kernel.org/all/20260331114742.2896317-5-mukesh.savaliya@oss.qualcomm.com/
Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>

When other drivers attempt I2C transfers during early resume phase, the
I2C controller is still runtime suspended, causing pm_runtime_get_sync()
to fail with -EACCES (-13):

  [  101.914202] geni_i2c 980000.i2c: error turning SE resources:-13

The PM runtime core returns -EACCES when runtime PM is disabled
(dev->power.disable_depth > 0). This occurs because:

1. During suspend_noirq, I2C driver calls geni_i2c_runtime_suspend()
   and then pm_runtime_disable()
2. I2C driver's noirq_resume only marks adapter as resumed but doesn't
   re-enable runtime PM or power up the hardware
3. Other drivers resuming later attempt I2C transfers
4. pm_runtime_get_sync() returns -EACCES because runtime PM is still
   disabled

Fix this by calling pm_runtime_force_resume() in geni_i2c_resume_noirq()
to properly resume the hardware and re-enable runtime PM during the noirq
phase. This ensures the I2C controller is powered and ready for use when
other drivers need it during resume.

Upstream-Status: Pending
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>

…s zero

In qcom_geni_serial_handle_rx_dma(), geni_se_rx_dma_unprep() clears
port->rx_dma_addr before SE_DMA_RX_LEN_IN is read. If the register is zero,
for example when the RX stale counter fires on an idle line, the handler
returns without calling geni_se_rx_dma_prep().

The next RX DMA interrupt then hits the !port->rx_dma_addr guard and
returns immediately, so the RX DMA buffer is never rearmed and later input
is lost.

Keep the handler on the rearm path when rx_in is zero. Warn about the
unexpected zero-length DMA completion, skip received-data handling, and
always call geni_se_rx_dma_prep().

Link: https://lore.kernel.org/all/20260528-serial-rx-0-byte-fix-v1-1-dc4e876c7368@oss.qualcomm.com/
Fixes: 2aaa43c ("tty: serial: qcom-geni-serial: add support for serial engine DMA")
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>

…t-hs

The qcom,geni-uart-hs compatible does not rely on the pm_runtime
framework for power management.

Calling pm_runtime_enable()/disable() in probe/remove is therefore
unnecessary and may lead to incorrect or redundant power management
handling.

Skip pm_runtime usage for this compatible and instead invoke
geni_serial_resources_on/off() directly from the .pm callbacks.

Signed-off-by: Sai Srinivas <saisrini@qti.qualcomm.com>
Signed-off-by: Anup Kulkarni <anup.kulkarni@oss.qualcomm.com>